There are a plethora of data communications protocols most of which were developed to meet a specific set of communication needs. For example, so-called "messaging" protocols were proposed and developed in the 1980's to address certain messaging applications like e-mail, phone mail, etc. The X.400 series of recommendations advanced by CCITT define one messaging protocol. Another more recent example of a data communications protocol is version 2.0 of the Telecator Data Paging (TDP) protocol specification recently published in 1995 by the Personal Communications Industry Association (PCIA). The TDP protocol suite is a set of communications protocols to provide data paging capabilities and is designed to support wireless one-way transmission of any type of binary data from an input device to a remote computer device via radio paging channels. As a result, different types of computers, Personal Digital Assistants (PDAs), and other portable devices can receive information transmitted over radio paging channels. Such information might be spreadsheet information, database updates, digitized fax, voice or video data, computer programs, or any other type of digitally encoded data. TDP was also designed in the hopes of supporting two-way paging applications for wireless devices like pagers and cellular phones where a paged device may return a response to the wireline or wireless message origination device.
In actuality, the TDP protocol suite includes a number of individual protocols including: a data input protocol known as the Telecator Message Entry (TME), a radio transport protocol known as Telecator Radio Transport (TRT), a radio receiver to remote computer data transfer protocol known as Telecator Mobile Computer (TMC), a Telecator Network Paging Protocol (TNPP) or Telecator Interswitch Paging Protocol (TIPP) utilized to move radio transmission data from one paging terminal to another, Telecator Format Conversion (TFC) used by a front end processor to send binary data through a port compatible with the Telecator Alpha-numeric Protocol (TAP), and a Wireless Message Format (WMF) which describes the format in which binary input data may initially be presented to a paging terminal. Ultimately, binary data initially sent from a Message Entry Device (MED) to a remote Mobile Computer Device (MCD) is expected to appear in the wireless message format for delivery to a pager.
The Telecator Message Entry (TME) protocol specifies certain rules for moving information between the MED and a paging network. The protocol expects entry device to "log in" to the paging system and possibly identify who the caller is, along with the specification of an optional password. For a particular set of binary data to transmit, one or more remote receivers may be specified so that the paging systems may forward the received data to the proper set of paging terminals which cover the geographic region where data transmission is to take place. Other TME control blocks allow input devices to define parameters such as the delivery priority, which specifies the desired time period within which the entire set of binary data should be transmitted.
The architecture of many data communication protocols follows the International Standards for Organization (ISO) structure for "layered protocols" beginning with an applications layer that defines the structure of the data and the control blocks which are transferred between two communicating devices. The application layer also defines the format of responses expected when control blocks are transferred. A transport layer defines how each application layer and control block is broken down into one or more packets so that they may be reliably moved between systems. The network routing layer defines how individual packets of the transport layer are properly directed to move between the two communicating devices if these devices are not directly connected to each other. The data link layer defines the structure of the data as it appears on a communications link. The data link layer defines how data bytes are represented so they are not confused with control information and how "check-sum" information is added to transmitted data so that the receiving data link layer software can detect transmission errors. Finally, the physical layer represents the physical hardware and driver control software which transmits and receives data bits over a communications circuit. To transfer message data, each layer in the stack performs its particular processing functions, advancing the processed information to the next layer in order to ultimately transmit data bits over the physical communications channel. When data is received on the channel, the process is reversed.
The particular layer of interest to the present invention is the application layer which defines communications procedures, data, and control structures used to move data and define control parameters between two devices. Two well known example applications that run on top of the application layer are electronic mail and electronic file transfer. Another example application of interest to the present invention is the transfer and delivery of short text messages between a message entry device and a messaging handling processor for delivery to a mobile radio terminal.
Generally, the structure of existing applications layers and the format of the control blocks are formally and rigidly defined by protocol notation known as Abstract Syntax Notation (ASN.1). ASN.1 is a formal language having a complex, encoded representation whose precise, formal nature removes any possible ambiguities from both representation and meaning. For example, instead of saying that a variable contains an integer value, a protocol designer who uses ASN.1 must state the exact form and range of the numeric values. More generally, ASN.1 defines precisely how to encode both names and data items in a message.
Unfortunately, ASN.1 has numerous and significant drawbacks including complexity, inflexibility, and high expense. The following is an example of just how complex it is just to log-in and confirm the log-in (before a message is even sent) using the TME protocol using ASN.1.
__________________________________________________________________________ // ASCII Representation of a Login Invoke PDU value LoginArgument::= loginID subscriberID: "tme_test", tmeVersion { majorVersion 2, minorVersion 0 } password "password" } // ASN.1 Representation of the Login Invoke PDU LoginArgument SEQUENCE [fieldcount (not encoded) = 3] loginID LoginId CHOICE [index = 0] suscriberId SubscriberId Character String [length = 8.0] "tme.sub.-- test" tmeVersion TmeVersion SEQUENCE [fieldcount (not encoded) = 2] majorVersion INTEGER [length = 1.0] 2 minorVersion INTEGER [length (not encoded) = 0.4] password Password Character String [length = 8.0] "password" Total PDV length = 22.0 // An ASN.1 Encoded output of the Login Invoke PDU TDPTypes CHOICE [index = 0] invoke SEQUENCE [fieldcount (not encoded) = 3] invokeID InvokeID CHOICE [index = 0] present INTEGER [length = 1.0] 1 opcode Code CHOICE [index = 0] local INTEGER [length = 1.0] 1 argument OpenType [length = 22.0] 0x4070746d655f746573740101010070617373776f7264 Total PDV length = 29.0 // Login Response PDU enclosed in a ROSE envelope. TDPTypes CHOICE [index = 1] returnResult SEQUENCE [fieldcount (not encoded) = 2] invokeId Invoke Id CHOICE [index = 0] present INTEGER [length = 1.0] 1 result SEQUENCE [fieldcount (not encoded) = 2] opcode Code CHOICE [index = 0] local INTEGER [length = 1.0] 1 result OpenType [length = 63.0] 0x4001010015313939936313130353039343932302e392d30353030002357656c636f6d65 . . . Total PDV length = 70.0 // Login Result after decoding-ASN.1 format. LoginResult SEQUENCE [fieldcount (not encoded) = 3] tmeVersion TmeVersion SEQUENCE [fieldcount (not encoded) = 2] majorVersion INTEGER [length = 1.0] 2 minorVersion INTEGER [length (not encoded) = 0.4] systemConfigDateTime GeneralizedTime [length = 21.0] 19961105094920.9-0500 carrierNewsflash Character String [length = 35.0] "Welcome to the Message Center [TME]" Total PDV length = 63.0 Received PDU:2 // Login Result ASCII representation. value LoginResult::= { tmeVersion { majorVersion 2, minorVersion 0 }, systemConfigDateTime "19961105094920.900-0500", carrierNewsflash "Welcome to the Message Center [TME]" } __________________________________________________________________________
From the above, it is plain that encoding a simple message just to deliver a login ID and password is amazingly complex.
Another problem with existing data communications protocols is they are increasingly antiquated. Current and future telecommunications systems require more comprehensive and more readily integratable features. For example, data are increasingly being sent over cellular digital packet data (CDPD) systems. Accordingly, for a message handling system to effectively interface with the CDPD system it must provide new services and features currently in demand but also must have the flexibility to adapt to and provide future communications needs.
A current example of a mobile data system/wireless computer network is the Public Land Mobile Network (PLMN). In such a network, mobile units such as cellular telephones may communicate with other mobile units through the PLMN or with stationary wireline units through more conventional wireline type networks such as the Public Switch Telephone Network (PSTN), the Internet, etc. More and more applications of mobile data systems require two-way communication to and from the mobile, wireless terminals. Even a relatively simple courier or taxi radio dispatch system where couriers/cabs are dispatched for a package pick-up should provide some return acknowledgment or confirmation message.
Unfortunately, many existing protocols are not well suited for such two-way data communications. For example, standardized protocols like the Telecator Data Paging (TDP) protocol suffer a number of limitations and drawbacks when messaging system designers and programmers try to put them into practice. Specifically, the TDP suite of protocols is directed and based on old paging protocols and paging networks and is not well directed to the special current needs, e.g., two-way data/text communications, of wireless mobile terminals or cellular telephones. Being directed to paging networks, TDP is not well suited to provide short text messaging services (SMS). SMS requires a much more flexible, comprehensive, and easily-used protocol to facilitate message transfer between a messaging service/operator and a message handling center for ultimate routing messages to and from a cellular telephone. In addition, the TME paging network controller permanently functions as the "server." "Client" devices are required to poll the network controller server to retrieve messages. It would be desirable to permit a messaging center to function both as a server and as a client that could independently initiate and send messages without first being polled. Another problem with the TME protocol is that its message delivery mechanism requires the use of a directory command which causes a list of message IDs to be sent to the client. Thereafter, the client must "pull" messages from the network server using a message reference. Such a message delivery approach is complex to implement because the number of messages is indeterminate. What is needed is a simple message delivery request mechanism that can be readily implemented and used.
Increasing demands for more capability and flexibility in communications protocol are further complicated by the need to keep portable radio terminals simple, small, and inexpensive. Because cellular telephones are already very small devices (and will get only smaller), they have limited amounts of memory and data processing capability. Because cellular telephones are battery-operated, power conservation is at a premium. As a result, cellular telephones are powered-off for long time periods. Another factor pertains to the fact that while some messages are for the human user of the cellular telephone, some messages are intended only for a computer located in the cellular telephone itself. For example, the telephone computer uses short messages for authentication, for activation or deactivation of cellular telephone features, etc. Factors like these make cellular telephone message delivery, confirmation, and origination quite challenging. Accordingly, a data communications protocol designed to optimally meet these challenges is needed.
Consider the following, real world situation where a telephone network operator provides a call answering service which permits a subscriber to call a special message service telephone number to have a text message delivered to a cellular telephone. After dialing the call answering service, the caller dictates over the phone a message which is typed into a message entry device by a human operator and sent on to a message handling center. The message handling center routes the message via the Public Land Mobile Network (PLMN) to the cellular telephone over a radio channel.
What is needed in this situation is a data communications language, i.e., protocol, that is easy for an operator to enter the message and transmit it quickly, efficiently, and with confirmation. The protocol should permit the cellular telephone to acknowledge whether and when the message is successfully delivered and stored in the memory of the cellular telephone. The protocol must also adapt to the fact that, as mentioned above, cellular telephones are often turned-off, and as a result, there may be a large number of unsuccessful message delivery attempts. So the protocol should permit an operator to replace a message that may not have been successfully delivered, stored, or retrieved by or during a certain time frame. The originating caller should also be able to receive a notification message if the original message could not be successfully delivered within the specified time period.
Priority of messages is also an important feature in delivering messages to and from cellular telephones since radio bandwidth is a precious resource. Given the limited memory of the cellular telephone, another desired feature is the ability to erase messages after a certain time to open up storage for new messages. The caller may also be interested in determining the status of the message, e.g., whether the message has been received, read, etc. Other features that must be accommodated for short messages delivered to cellular telephones are variable message length capability and transmission to multiple destinations, e.g., multiple cellular telephones.
Of course, an important feature in a two-way messaging system is sending a message or other notification report from the messaging center to the message entry device. This "reverse" communications direction is not typically found for example in traditional paging systems. What is needed is a protocol that permits messages to be sent just as easily from a message handling center to an operator as from an operator to a message handling center without any special alerting function or polling operation.
As already described, a major problem with existing protocols is the use of very complicated encoding procedures, i.e., ASN.1 encoding. In addition, ASN.1 requires that an operator provide information for every required field. This is often inconvenient and unnecessary when certain fields do not apply for a particular message. In any event, ASN.1 transcoders are quite expensive, difficult to program against, complex to implement, and complex to debug. An encoding technique is needed that provides an unambiguous representation of communication variables, that is also easily understood by humans, and that is easy to decode. Moreover, the operator should not have to remember and be proficient with many different commands to program new features or new applications that are to run on top of this protocol. Programming new features or service elements should be straightforward, and the protocol should not be adversely impacted by inevitable changes and expansions in communications services.
The present invention provides a new protocol which meets these needs and overcomes these and other drawbacks with existing communications protocols. The protocol in accordance with the present invention employs a small set of simple transactional commands to effect communications between two computers and finds particularly advantageous application to short text message, two-way data communications between a message entry device and a message handling center for communicating messages to and from cellular telephones. Therefore, the protocol finds particular application to Public Land Mobile Networks (PLMN). The new protocol in accordance with the present invention, referred to as Computer Access Protocol (CAP II), is an application layer protocol which is independent of underlying layers. As such, the CAP II protocol may be used "on top of" standard lower layer protocols such as TCP/IP or X.25.
CAP II defines a client-server model where the client is the entity which establishes the connection, and the server is the entity to which the connection is established. Both the message entry device and the message handling center may function as a client and as a server. In this regard, CAP II is symmetrical in that communicating devices function as "peers," and there is no need for special alerts or polling by one device to receive messages from another device. Communicating devices may function in one communication as a "server" and in another as a "client." Human-readable, ASCII Protocol Data Units (PDUs) are exchanged between client and server.
Message encoding is easy to implement and use. An input message is encapsulated by a message entry device between first and second delimiters, e.g., "{" and "}", and a message tag is associated with the encapsulated message. Both the message tag and the encapsulated message are in human-readable, ASCII format. The delimited message and associated message tag are further encapsulated by, i.e., "nested" in, additional delimiters with one or more corresponding tags to form a protocol data unit that also has an associated protocol data unit tag. Message decoding is also easy. The receiving unit, e.g., a message handling center, receives binary symbols corresponding to the transmitted PDU and converts those received binary symbols into ASCII format. The resulting PDU is then parsed using the delimiters and associated tags to unpack the message. This parsing process is readily performed because the delimiters are easily detected and each tag identifies the content of the delimited information with which the tag is associated. Accordingly, no complicated encoding or decoding procedures are necessary.
In the particular application of the CAP II protocol to messaging services provided by a messaging handling center for processing messages between a message entry device and portable radios such as cellular telephones, the message handling center provides a plurality of messaging services including storing messages in electronic form and forwarding specific messages to destination devices under prescribed conditions. A mobile radio communications network connected to the message handling center includes several radio base stations for communicating voice and data call information over radio channels with portable radios within each radio base station's range. A message service center receives calls from persons who want to deliver text messages to portable radios. A human operator at the message service center enters a text message via a message entry device connected to the message handling center. The message entry device includes a data processor for encoding the text message and associated control information using the delimiters and delimiter tag described above to generate PDUs which are transmitted to the message handling center. The message handling center receives the PDUs, parses out the various field information and message tags, and delivers the text message to the appropriate portable radio by way of the mobile radio network and radio base station in accordance with the control information.
Significantly, the message handling center also receives messages generated by portable radios by way of the mobile communications network. A data processor in the message handling center encodes the radio text message and any related control information using the delimiter/tag encapsulation method described above to generate one or more PDUs which are transmitted to the message entry device. When the message entry device receives the PDUs, it parses out the text messaging control information using the delimiters and tags.
One of the message entry device and message handling center initiating a communication connection between the message entry device and message handling center is defined as a client and the other is defined as the server. Either the message entry device or the message handling center may independently initiate a communications connection as the client. A set of human-readable transaction commands is used by the client and server to transmit information over the established communications connection. Each transactional command includes a transaction request PDU sent from the client which initiates the transaction and a transaction confirm protocol data unit sent from the server which confirms whether the transaction request is successful. Some of the transactions may be marked to indicate that they include plural PDUs thereby binding the plural PDUs to the same transaction.
The set of human-readable transactional commands includes a BIND transaction used by the client to initiate a communications session between the client and server to permit plural transaction request PDUs and transaction confirm PDUs to be exchanged during the communications session. An UNBIND transaction is used to end the communications session. The set of transactions further includes a SUBMIT transaction initiated by the client to submit a message to the server, a DELIVER transaction initiated by the client to retrieve to message from the server; a REMOVE transaction initiated by the message entry device to delete a message stored in the message handling center; a REPLACE transaction initiated by the message entry device to replace a message stored in the message handling center; an INQUIRE transaction initiated by the client to inquire about the status of an earlier submitted message.
Many of the transaction commands include plural parameter fields encoded and decoded using corresponding tags and delimiters. Each parameter specifies a particular operation to be performed with respect to a submitted message. For example, plural destination addresses may be specified to transmit a PDU to plural different destinations. A deferred delivery time may be employed to specify when an attempt should be made to transmit the message. A priority may be associated with the message to control the order in which the message is transmitted, with higher priority messages being transmitted before lower priority messages. A message expiration time may be attached to the message after which expiration no further attempts will be made to transmit the message. A message delivery status may be used to inform the device submitting the message whether the message was successfully delivered, and if not, the reason for the failed delivery. A confirmation parameter indicates whether confirmation PDUs should be suppressed in order, for example, to facilitate transmission of long messages. A transaction reference is assigned by the originator of the transaction request. The transaction request is used to match a pending transaction request with a received transaction confirm. Other parameters include a maximum transaction window that represents the maximum number of outstanding transaction requests pending a confirmed transaction.